Reacts hemmelige ingrediens: Et dypdykk i Reconciliation-algoritmen og Virtual DOM-diffing

` representeres slik:

{ type: 'div', props: { className: 'container', children: 'Hello World' } }

Fordi dette bare er JavaScript-objekter, er det utrolig raskt å opprette og manipulere dem. Det innebærer ingen interaksjon med nettleser-API-er, så det er ingen reflows eller repaints.

Hvordan fungerer Virtual DOM?

VDOM muliggjør en deklarativ tilnærming til UI-utvikling. I stedet for å fortelle nettleseren hvordan den skal endre DOM trinn for trinn (imperativt), erklærer du bare hvordan brukergrensesnittet skal se ut for en gitt state (deklarativt). React håndterer resten.

Prosessen ser slik ut:

1. Første rendering: Når applikasjonen din lastes for første gang, oppretter React et komplett Virtual DOM-tre for brukergrensesnittet ditt og bruker det til å generere det opprinnelige, virkelige DOM.
2. State-oppdatering: Når applikasjonens state endres (f.eks. en bruker klikker på en knapp), oppretter React et nytt Virtual DOM-tre som reflekterer den nye state.
3. Diffing: React har nå to Virtual DOM-trær i minnet: det gamle (før state-endringen) og det nye. Deretter kjører den sin "diffing"-algoritme for å sammenligne disse to trærne og identifisere de nøyaktige forskjellene.
4. Batching og oppdatering: React beregner det mest effektive og minimale settet med operasjoner som kreves for å oppdatere det virkelige DOM slik at det samsvarer med det nye Virtual DOM. Disse operasjonene batches sammen og brukes på det virkelige DOM i en enkelt, optimalisert sekvens.

Ved å batche oppdateringer minimerer React direkte interaksjon med det trege DOM, noe som forbedrer ytelsen betydelig. Kjernen i denne effektiviteten ligger i "diffing"-steget, som formelt er kjent som Reconciliation-algoritmen.

Hjertet av React: Reconciliation-algoritmen

Reconciliation er prosessen der React oppdaterer DOM for å matche det siste komponenttreet. Algoritmen som utfører denne sammenligningen er det vi kaller "diffing-algoritmen."

Teoretisk sett er det å finne det minimale antallet transformasjoner for å konvertere ett tre til et annet et svært komplekst problem, med en algoritmekompleksitet i størrelsesorden O(n³), der n er antall noder i treet. Dette ville vært for tregt for virkelige applikasjoner. For å løse dette, gjorde React-teamet noen geniale observasjoner om hvordan webapplikasjoner vanligvis oppfører seg og implementerte en heuristisk algoritme som er mye raskere – den opererer i O(n)-tid.

Heuristikken: Gjør diffing raskt og forutsigbart

Reacts diffing-algoritme er bygget på to primære antakelser eller heuristikker:

Heuristikk 1: Forskjellige elementtyper produserer forskjellige trær

Dette er den første og mest rett-frem regelen. Når React sammenligner to VDOM-noder, ser den først på typen deres. Hvis typen til rotelementene er forskjellig, antar React at utvikleren ikke ønsker å prøve å konvertere den ene til den andre. I stedet tar den en mer drastisk, men forutsigbar tilnærming:

• Den river ned hele det gamle treet, demonterer alle gamle komponenter og ødelegger deres state.
• Den bygger et helt nytt tre fra bunnen av basert på den nye elementtypen.

For eksempel, vurder denne endringen:

Før: <div><Counter /></div>
Etter: <span><Counter /></span>

Selv om barnekomponenten `Counter` er den samme, ser React at roten har endret seg fra en `div` til en `span`. Den vil fullstendig demontere den gamle `div`-en og `Counter`-instansen inni den (og dermed miste dens state), og deretter montere en ny `span` og en helt ny instans av `Counter`.

Nøkkelinnsikt: Unngå å endre rotelementtypen til et komponent-subtre hvis du vil bevare dens state eller unngå en full re-rendering av det subtreet.

Heuristikk 2: Utviklere kan hinte om stabile elementer med `key`-propen

Dette er uten tvil den mest kritiske heuristikken for utviklere å forstå og anvende korrekt. Når React sammenligner en liste med barneelementer, er standardoppførselen å iterere over begge listene med barn samtidig og generere en mutasjon der det er en forskjell.

Problemet med indeksbasert diffing

La oss forestille oss at vi har en liste med elementer, og vi legger til et nytt element i begynnelsen av listen uten å bruke keys.

Opprinnelig liste:

• Element B
• Element C

Oppdatert liste (legg til 'Element A' i starten):

• Element A
• Element B
• Element C

Uten keys utfører React en enkel, indeksbasert sammenligning:

1. Den sammenligner det gamle elementet på indeks 0 ('Element B') med det nye elementet på indeks 0 ('Element A'). De er forskjellige, så den muterer det første elementet.
2. Den sammenligner det gamle elementet på indeks 1 ('Element C') med det nye elementet på indeks 1 ('Element B'). De er forskjellige, så den muterer det andre elementet.
3. Den ser at det er et nytt element på indeks 2 ('Element C') og setter det inn.

Dette er svært ineffektivt. React har utført to unødvendige mutasjoner og én innsetting, når alt som trengtes var en enkelt innsetting i begynnelsen. Hvis disse listeelementene var komplekse komponenter med sin egen state, kunne dette ført til alvorlige ytelsesproblemer og feil, ettersom state kunne bli blandet mellom komponenter.

Kraften i `key`-propen

`key`-propen gir en løsning. Det er et spesielt strengattributt du må inkludere når du lager lister med elementer. Keys gir React en stabil identitet for hvert element.

La oss se på det samme eksempelet igjen, men denne gangen med stabile, unike keys:

Opprinnelig liste:

• Element B
• Element C

Oppdatert liste:

• Element A
• Element B
• Element C

Nå er Reacts diffing-prosess mye smartere:

1. React ser på barna i den nye listen og finner elementer med keys 'b' og 'c'.
2. Den vet at elementene med keys 'b' og 'c' allerede eksisterer i den gamle listen, så den flytter dem bare.
3. Den ser at det er et nytt element med key 'a' som ikke eksisterte før, så den oppretter og setter det inn.

Dette er langt mer effektivt. React identifiserer korrekt at den bare trenger å utføre én innsetting. Komponentene knyttet til keys 'b' og 'c' bevares, og beholder sin interne state.

Kritisk regel for keys: Keys må være stabile, forutsigbare og unike blant sine søsken. Å bruke array-indeksen som key (`items.map((item, index) =>

...

)`) er et anti-mønster hvis listen noen gang kan bli omorganisert, filtrert, eller få elementer lagt til/fjernet fra midten, da det fører til de samme problemene som å ikke ha noen key i det hele tatt. De beste keys er unike identifikatorer fra dataene dine, som en database-ID.

Evolusjonen: Fra Stack- til Fiber-arkitektur

Reconciliation-algoritmen beskrevet ovenfor var grunnlaget for React i mange år. Den hadde imidlertid én stor begrensning: den var synkron og blokkerende. Denne opprinnelige implementeringen blir nå referert til som Stack Reconciler.

Den gamle måten: Stack Reconciler

I Stack Reconciler, når en state-oppdatering utløste en re-rendering, ville React rekursivt traversere hele komponenttreet, beregne endringene og anvende dem på DOM – alt i en enkelt, uavbrutt sekvens. For små oppdateringer var dette greit. Men for store komponenttrær kunne denne prosessen ta betydelig tid (f.eks. mer enn 16ms), og blokkere nettleserens hovedtråd. Dette ville føre til at brukergrensesnittet ble uresponsivt, noe som resulterte i tapte frames, hakkete animasjoner og en dårlig brukeropplevelse.

Introduksjon av React Fiber (React 16+)

For å løse dette problemet, gjennomførte React-teamet et flerårig prosjekt for å omskrive kjerne-reconciliation-algoritmen fullstendig. Resultatet, utgitt i React 16, kalles React Fiber.

Fiber-arkitekturen ble designet fra bunnen av for å muliggjøre concurrency—evnen for React til å jobbe med flere oppgaver samtidig og bytte mellom dem basert på prioritet.

En "fiber" er et rent JavaScript-objekt som representerer en arbeidsenhet. Den inneholder informasjon om en komponent, dens input (props) og dens output (children). I stedet for en rekursiv traversering som ikke kunne avbrytes, prosesserer React nå en lenket liste med fiber-noder, en om gangen.

Denne nye arkitekturen låste opp flere sentrale muligheter:

• Inkrementell rendering: Den kan dele opp renderingsarbeid i små biter og spre det ut over flere frames.
• Prioritering: Den kan tildele forskjellige prioritetsnivåer til forskjellige typer oppdateringer. For eksempel har en bruker som skriver i et input-felt høyere prioritet enn data som hentes i bakgrunnen.
• Mulighet for pause og avbrudd: Den kan sette arbeid på en lavprioritert oppdatering på pause for å håndtere en høyprioritert en, og kan til og med avbryte eller gjenbruke arbeid som ikke lenger er nødvendig.

De to fasene i Fiber

Under Fiber er renderingsprosessen delt inn i to distinkte faser:

1. Render/Reconciliation-fasen (Asynkron): I denne fasen prosesserer React fiber-noder for å bygge et "work-in-progress"-tre. Den kaller komponenters `render`-metoder og kjører diffing-algoritmen for å bestemme hvilke endringer som må gjøres i DOM. Avgjørende er at denne fasen er avbrytbar. React kan sette dette arbeidet på pause for å håndtere noe viktigere, og gjenoppta det senere. Fordi den kan avbrytes, anvender ikke React noen faktiske DOM-endringer i denne fasen for å unngå en inkonsistent UI-state.
2. Commit-fasen (Synkron): Når work-in-progress-treet er komplett, går React inn i commit-fasen. Den tar de beregnede endringene og anvender dem på det virkelige DOM. Denne fasen er synkron og kan ikke avbrytes. Dette sikrer at brukeren alltid ser et konsistent brukergrensesnitt. Livssyklusmetoder som `componentDidMount` og `componentDidUpdate`, samt `useLayoutEffect`- og `useEffect`-hooks, kjøres i løpet av denne fasen.

Fiber-arkitekturen er grunnlaget for mange av Reacts moderne funksjoner, inkludert `Suspense`, concurrent rendering, `useTransition` og `useDeferredValue`, som alle hjelper utviklere med å bygge mer responsive og flytende brukergrensesnitt.

Praktiske optimaliseringsstrategier for utviklere

Å forstå Reacts reconciliation-prosess gir deg kraften til å skrive mer ytelseseffektiv kode. Her er noen handlingsrettede strategier:

1. Bruk alltid stabile og unike keys for lister

Dette kan ikke understrekes nok. Det er den desidert viktigste optimaliseringen for lister. Bruk en unik ID fra dataene dine (f.eks. `product.id`). Unngå å bruke array-indekser med mindre listen er helt statisk og aldri vil endre seg.

2. Unngå unødvendige re-renderinger

En komponent re-renderes hvis dens state endres eller dens forelder re-renderes. Noen ganger re-renderes en komponent selv om outputen ville vært identisk. Du kan forhindre dette ved å bruke:

• `React.memo()`: En higher-order component for funksjonskomponenter. Den utfører en overfladisk sammenligning av komponentens props. Hvis props ikke har endret seg, vil React hoppe over re-rendering av komponenten og gjenbruke det sist renderede resultatet.
• `useCallback()`: Funksjoner definert inne i en komponent blir gjenskapt ved hver rendering. Hvis du sender disse funksjonene ned som props til en barnekomponent som er wrappet i `React.memo`, vil barnet re-rendere fordi funksjons-propen teknisk sett er en ny funksjon hver gang. `useCallback` memoiserer selve funksjonen, og sikrer at den bare blir gjenskapt hvis dens avhengigheter endres.
• `useMemo()`: Ligner på `useCallback`, men for verdier. Den memoiserer resultatet av en kostbar beregning. Beregningen kjøres bare på nytt hvis en av dens avhengigheter har endret seg. Dette er nyttig for å forhindre kostbare beregninger ved hver rendering og for å opprettholde stabile objekt-/array-referanser som sendes som props.

3. Smart komponentkomposisjon

Måten du strukturerer komponentene dine på kan ha en betydelig innvirkning på ytelsen. Hvis en del av komponentens state oppdateres ofte, prøv å isolere den fra de delene som ikke gjør det.

For eksempel, i stedet for å ha én stor komponent der et ofte endret input-felt fører til at hele komponenten re-renderes, løft den state-en inn i sin egen mindre komponent. På denne måten er det bare den lille komponenten som re-renderes når brukeren skriver.

4. Virtualiser lange lister

Hvis du trenger å rendere lister med hundrevis eller tusenvis av elementer, kan det være tregt og bruke mye minne å rendere alle på en gang, selv med riktige keys. Løsningen er virtualisering eller windowing. Denne teknikken innebærer å kun rendere det lille delsettet av elementer som for øyeblikket er synlige i viewporten. Når brukeren scroller, demonteres gamle elementer, og nye elementer monteres. Biblioteker som `react-window` og `react-virtualized` tilbyr kraftige og brukervennlige komponenter for å implementere dette mønsteret.

Konklusjon

Reacts ytelse er ingen tilfeldighet; det er resultatet av en bevisst og sofistikert arkitektur sentrert rundt Virtual DOM og en effektiv Reconciliation-algoritme. Ved å abstrahere bort direkte DOM-manipulering, kan React batche og optimalisere oppdateringer på en måte som ville vært utrolig kompleks å håndtere manuelt.

Som utviklere er vi en avgjørende del av denne prosessen. Ved å forstå heuristikken i diffing-algoritmen – ved å bruke keys korrekt, ved å memo-isere komponenter og verdier, og ved å strukturere applikasjonene våre gjennomtenkt – kan vi jobbe med Reacts reconciler, ikke mot den. Evolusjonen til Fiber-arkitekturen har ytterligere flyttet grensene for hva som er mulig, og muliggjør en ny generasjon av flytende og responsive brukergrensesnitt.

Neste gang du ser brukergrensesnittet ditt oppdateres umiddelbart etter en state-endring, ta et øyeblikk til å verdsette den elegante dansen mellom Virtual DOM, diffing-algoritmen og commit-fasen som skjer under panseret. Denne forståelsen er nøkkelen din til å bygge raskere, mer effektive og mer robuste React-applikasjoner for et globalt publikum.